Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / networking / mail / mh / doc / ADMIN.doc < prev next >

Wrap

Text File | 1993-08-20 | 88KB | 2,905 lines

_d_i_s_c_a_r_d _t_h_i_s _p_a_g_e The RAND _M_H Message Handling System: Administrator's Guide UCI Version August 20, 1993 6.8.1 #1[UCI] _1. _I_N_T_R_O_D_U_C_T_I_O_N _S_c_o_p_e _o_f _t_h_i_s _d_o_c_u_m_e_n_t This is the Administrator's Guide to _M_H. If you don't maintain an _M_H system, don't read this; the information is entirely too technical. If you are a maintainer, then read this guide until you understand it, follow the advice it gives, and then forget about the guide. Before continuing, I'll point out two facts: _T_h_i_s _d_o_c_u_m_e_n_t _w_i_l_l _n_e_v_e_r _c_o_n_t_a_i_n _a_l_l _t_h_e _i_n_f_o_r_m_a_t_i_o_n _y_o_u _n_e_e_d _t_o _m_a_i_n_t_a_i_n _M_H. _F_u_r_t_h_e_r_m_o_r_e, _t_h_i_s _d_o_c_u_m_e_n_t _w_i_l_l _n_e_v_e_r _c_o_n_t_a_i_n _e_v_e_r_y_t_h_i_n_g _I _k_n_o_w _a_b_o_u_t _m_a_i_n_t_a_i_n_i_n_g _M_H. _M_H, and mailsystems in general, are more complex than most people real- ize. A combination of experience, intuition, and tenacity is required to maintain _M_H properly. This document can provide only guidelines for bringing up an _M_H system and maintaining it. There is a sufficient amount of customization possible that not all events or problems can be forseen. _S_u_m_m_a_r_y During _M_H generation, you specify several configuration constants to the _m_h_c_o_n_f_i_g program. These directives take into consideration such issues as hardware and operating system dependencies in the source code. They also factor out some major mailsystem administrative decisions that are likely to be made consistantly at sites with more than one host. The manual entry _m_h-_g_e_n (8) describes all the static configuration directives. However, when you install _M_H you may wish to make some site-specific or host-specific changes which aren't hardware or even software related. Rather, they are administrative decisions. That's what this guide is for: it describes all of the dynamically tailorable directives. -2- Usually, after installing _M_H, you'll want to edit the /usr/local/lib/mh-6.8/mtstailor file. This file fine-tunes the way _M_H interacts with the message transport system (MTS). Section 2 talks about the MTS interface and MTS tailoring. After that, if you're running the UCI BBoards facility, or the POP facility, you'll need to know how to maintain those systems. Sections 3 and 4 talk about these. If for some reason you're not running an MTS that can handle both Internet and _U_U_C_P traffic, you should read-up on mail filtering in Sec- tion 5. Although this is considered "old technology" now, the mechan- isms described in Section 5 were really quite useful when first intro- duced way back in 1981. Finally, you may want to know how to modify the _M_H source tree. Section 6 talks (a little bit) about that. The last two sections describe a few hidden features in _M_H, and the configuration options that were in effect when this guide was generated. After _M_H is installed, you should define the address "Bug-MH" to map to either you or the _P_o_s_t_M_a_s_t_e_r at your site. In addition, if you want to tailor the behavior of _M_H for new users, you can create and edit the file /usr/local/lib/mh- 6.8/mh.profile. When the _i_n_s_t_a_l_l-_m_h program is run for a user, if this file exists, it will copy it into the user's .mh_profile file. _2. _T_H_E _M_T_S _I_N_T_E_R_F_A_C_E The file /usr/local/lib/mh-6.8/mtstailor customizes certain host-specific parameters of _M_H related primarily to interactions with the transport system. The parameters in this file override the compiled-in defaults given during _M_H configuration. Rather than recom- piling _M_H on each host to make minor customizations, it is easier simply to modify the mtstailor file. All hosts at a given site normally use the same mtstailor file, though this need not be the case. It is a good idea to run the _c_o_n_f_l_i_c_t (8) program each morning under _c_r_o_n. The following line usually suffices: 00 05 * * * /usr/local/lib/mh-6.8/conflict -mail PostMaster -3- MH-TAILOR(5) -4- MH-TAILOR(5) _N_A_M_E mh-tailor, mtstailor - system customization for MH message handler _S_Y_N_O_P_S_I_S /_u_s_r/_l_o_c_a_l/_l_i_b/_m_h-_6._8/_m_t_s_t_a_i_l_o_r _D_E_S_C_R_I_P_T_I_O_N The file /usr/local/lib/mh-6.8/mtstailor defines run-time options for those _M_H programs which interact (in some form) with the mes- sage transport system. At present, these (user) programs are: _a_p, _c_o_n_f_l_i_c_t, _i_n_c, _m_s_g_c_h_k, _m_s_h, _p_o_s_t, _r_c_v_d_i_s_t, and _r_c_v_p_a_c_k. Each option should be given on a single line. Blank lines and lines which begin with `#' are ignored. The options available along with default values and a description of their meanings are listed below: localname: The host name _M_H considers local. If not set, depending on the version of UNIX you're running, _M_H will query the system for this value (e.g., <whoami.h>, gethostname, etc.). This has no equivalent in the _M_H configuration file. POP client hosts have this value set to the name of the POP service host. localdomain: If this is set, a `.' followed by this string will be appended to your host name. This might be useful for sites where the host name returned by the system (e.g., <whoami.h>, gethost- name, etc.), is not a "fully qualified domain name" (i.e., does not contain a `.'). systemname: The name of the local host in the _U_U_C_P "domain". If not set, depending on the version of UNIX you're running, _M_H will query the system for this value. This has no equivalent in the _M_H configuration file. mmdfldir: /usr/spool/mail The directory where maildrops are kept. If this is empty, the user's home directory is used. This overrides the "mail" field in the _M_H configuration file. mmdflfil: The name of the maildrop file in the directory where maildrops are kept. If this is empty, the user's login name is used. This overrides the "mail" field in the _M_H configuration file. mmdelim1: \001\001\001\001\n The beginning-of-message delimiter for maildrops. [mh.6] MH.6.8 UCI version MH-TAILOR(5) -5- MH-TAILOR(5) mmdelim2: \001\001\001\001\n The end-of-message delimiter for maildrops. mmailid: 0 If non-zero, then support for MMailids in /etc/passwd is enabled. Basically, the pw_gecos field in the password file is of the form My Full Name <mailid> The _M_H internal routines that deal with user and full names will return "mailid" and "My Full Name" respectively. lockstyle: 0 The locking discipline to perform. A value of "0" means to use kernel-level locking if available. (See below for more details.) On systems compiled without kernel-level locking, standard _B_e_l_l_M_a_i_l locking is used. A value of "1" means to use _B_e_l_l_M_a_i_l locking always (the name of the lock is based on the file name). A value of "2" means to use _M_M_D_F locking always (the name of the lock is based on device/inode pairs). lockldir: The name of the directory for making locks. If your system isn't configured to use kernel-level locking, then this direc- tory is used when creating locks. If the value is empty, then the directory of the file to be locked is used. maildelivery: /usr/local/lib/mh-6.8/maildelivery The name of the system-wide default ._m_a_i_l_d_e_l_i_v_e_r_y file. See _m_h_o_o_k (1) for the details. everyone: 200 The highest user-id which should NOT receive mail addressed to "everyone". noshell: If set, then each user-id greater than "everyone" that has a login shell equivalent to the given value (e.g., "/bin/csh") indicates that mail for "everyone" should not be sent to them. This is useful for handling admin, dummy, and guest logins. _M_a_i_l _F_i_l_t_e_r_i_n_g These options are only available if you compiled _M_H with "options MF". uucpchan: name of _U_U_C_P channel Usually "UUCP". This has no equivalent in the _M_H configura- tion file. uucpldir: /usr/spool/mail [mh.6] MH.6.8 UCI version MH-TAILOR(5) -6- MH-TAILOR(5) The name of the directory where _U_U_C_P maildrops are kept. This has no equivalent in the _M_H configuration file. uucplfil: The name of the maildrop file in the directory where _U_U_C_P maildrops are kept. If this is empty, the user's login name is used. This has no equivalent in the _M_H configuration file. umincproc: /usr/local/lib/mh-6.8/uminc The path to the program that filters _U_U_C_P-style maildrops to _M_M_D_F-style maildrops. _S_t_a_n_d-_A_l_o_n_e _D_e_l_i_v_e_r_y These options are only available if you compiled _M_H to use stand- alone delivery (i.e., "mts: mh"). mailqdir: /usr/spool/netmail The directory where network mail is queued. tmailqdir: /usr/tmp The directory where network mail queue files are built. syscpy: 1 If ON, unauthorized mail is copied to the overseer. overseer: root The user that receives reports of unauthorized mail. mailer: root The user acting for the mail system. fromtmp: /tmp/rml.f.XXXXXX The _m_k_t_e_m_p template for storing from lines. msgtmp: /tmp/rml.m.XXXXXX The _m_k_t_e_m_p template for storing the rest of the message. errtmp: /tmp/rml.e.XXXXXX The _m_k_t_e_m_p template for storing error messages from other mailers. tmpmode: 0600 The octal mode which temporary files are set to. okhosts: /usr/local/lib/mh-6.8/Rmail.OKHosts A file containing a list of hosts that can send ARPAnet mail. okdests: /usr/local/lib/mh-6.8/RMail.OKDests A file containing a list of hosts that can always receive mail. [mh.6] MH.6.8 UCI version MH-TAILOR(5) -7- MH-TAILOR(5) _T_h_e `/_s_m_t_p' _M_T_S _S_u_f_f_i_x These options are only available if you compiled _M_H with the "/smtp" suffix to your "mts:" configuration. hostable: /usr/local/lib/mh-6.8/hosts The exceptions file for /etc/hosts used by _p_o_s_t to try to find official names. The format of this file is quite simple: 1. Comments are surrounded by sharp (`#') and newline. 2. Words are surrounded by white space. 3. The first word on the line is the official name of a host. 4. All words following the official names are aliases for that host. servers: localhost \01localnet A lists of hosts and networks which to look for SMTP servers when posting local mail. It turns out this is a major win for hosts which don't run an message transport system. The value of "servers" should be one or more items. Each item is the name of either a host or a net (in the latter case, precede the name of the net by a \01). This list is searched when looking for a smtp server to post mail. If a host is present, the SMTP port on that host is tried. If a net is present, the SMTP port on each host in that net is tried. Note that if you are running with the BIND code, then any networks specified are ignored (sorry, the interface went away under BIND). _S_e_n_d_M_a_i_l This option is only available if you compiled _M_H to use _S_e_n_d_M_a_i_l as your delivery agent (i.e., "mts: sendmail"). sendmail: /usr/lib/sendmail The pathname to the _s_e_n_d_m_a_i_l program. _P_o_s_t _O_f_f_i_c_e _P_r_o_t_o_c_o_l This option is only available if you compiled _M_H with POP support enabled (i.e., "pop: on"). pophost: The name of the default POP service host. If this is not set, then _M_H looks in the standard maildrop areas for waiting mail, otherwise the named POP service host is consulted. _B_B_o_a_r_d_s _D_e_l_i_v_e_r_y This option is only available if you compiled _M_H with "bbdelivery: on". [mh.6] MH.6.8 UCI version MH-TAILOR(5) -8- MH-TAILOR(5) bbdomain: The local BBoards domain (a UCI hack). _B_B_o_a_r_d_s & _T_h_e _P_O_P These options are only available if you compiled _M_H with "bboards: pop" and "pop: on". popbbhost: The POP service host which also acts as a BBoard server. This variable should be set on the POP BBoards client host. popbbuser: The guest account on the POP/BB service host. This should be a different login ID than either the POP user or the BBoards user. (The user-id "ftp" is highly recommended.) This vari- able should be set on both the POP BBoards client and service hosts. popbblist: /usr/local/lib/mh-6.8/hosts.popbb A file containing of lists of hosts that are allowed to use the POP facility to access BBoards using the guest account. If this file is not present, then no check is made. This variable should be set on the POP BBoards service host. _B_B_o_a_r_d_s & _T_h_e _N_N_T_P This option is only available if you compiled _M_H with "bboards: nntp" and "pop: on". nntphost: The host which provides the NNTP service. This variable should be set on the NNTP BBoards client host. _F_i_l_e _L_o_c_k_i_n_g A few words on locking: _M_H has a flexible locking system for making locks on files. There are two mtstailor variables you should be aware of "lockstyle" and "lockldir". The first controls the method of locking, the second says where lock files should be created. The "lockstyle" variable can take on three values: 0, 1, 2. A value of 0 is useful on systems with kernel-level locking. If you are on a BSD42 system, _M_H assumes you have the _f_l_o_c_k system call. On other systems: define FLOCK if you want to use the _f_l_o_c_k system call; define LOCKF if you want to use the _l_o_c_k_f system call; or define FCNTL if you want to use the _f_c_n_t_l system call for kernel- level locking. If you haven't configured _M_H to use kernel-level locking, a locking style of 0 is considered the same as locking style 1. A value of 1 or 2 specifies that a file should be created whose [mh.6] MH.6.8 UCI version MH-TAILOR(5) -9- MH-TAILOR(5) existence means "locked" and whose non-existence means "unlocked". A value of 1 says to construct the lockname by appending ".lock" to the name of the file being locked. A value of 2 says to construct the lockname by looking at the device and inode numbers of the file being locked. If the "lockldir" variable is not specified, lock files will be created in the directory where the file being locked resides. Otherwise, lock files will be created in the directory specified by "lockldir". Prior to installing _M_H, you should see how locking is done at your site, and set the appropriate values. _F_i_l_e_s /usr/local/lib/mh-6.8/mtstailor tailor file _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s None _S_e_e _A_l_s_o mh-gen(8), mh-mts(8) _D_e_f_a_u_l_t_s As listed above _C_o_n_t_e_x_t None [mh.6] MH.6.8 UCI version MH-MTS(8) -10- MH-MTS(8) _N_A_M_E mh-mts - the MH interface to the message transport system _S_Y_N_O_P_S_I_S SendMail Zmailer MMDF (any release) stand-alone _D_E_S_C_R_I_P_T_I_O_N _M_H can use a wide range of message transport systems to deliver mail. Although the _M_H administrator usually doesn't get to choose which MTS to use (since it's already in place), this document briefly describes the interfaces. When communicating with _S_e_n_d_M_a_i_l, _M_H always uses the SMTP to post mail. Depending on the _M_H configuration, _S_e_n_d_M_a_i_l may be invoked directly (via a _f_o_r_k and an _e_x_e_c), or _M_H may open a TCP/IP connec- tion to the SMTP server on the localhost. When communicating with _z_m_a_i_l_e_r, the _S_e_n_d_M_a_i_l compatibility program is required to be installed in /usr/lib. _M_H communicates with _z_m_a_i_l_e_r by using the SMTP. It does this by invoking the /usr/lib/sendmail compatibility program directly, with the `-bs' option. When communicating with _M_M_D_F, normally _M_H uses the "mm_" routines to post mail. However, depending on the _M_H configuration, _M_H instead may open a TCP/IP connection to the SMTP server on the localhost. When using the stand-alone system (NOT recommended), _M_H delivers local mail itself and queues _U_U_C_P and network mail. The network mail portion will probably have to be modified to reflect the local host's tastes, since there is no well-known practice in this area for all types of UNIX hosts. If you are running a UNIX system with TCP/IP networking, then it is felt that the best interface is achieved by using either _S_e_n_d_M_a_i_l or _M_M_D_F with the SMTP option. This gives greater flexibility. To enable this option you append the /smtp suffix to the mts option in the _M_H configuration. This yields two primary advantages: First, you don't have to know where _s_u_b_m_i_t or _S_e_n_d_M_a_i_l live. This means that _M_H binaries (e.g., _p_o_s_t ) don't have to have this information hard-coded, or can run different programs altogether; and, second, you can post mail with the server on different systems, so you don't need either _M_M_D_F or _S_e_n_d_M_a_i_l on your local host. Big win in conserving cycles and disk space. Since _M_H supports the notion of [mh.6] MH.6.8 UCI version MH-MTS(8) -11- MH-MTS(8) a server search-list in this respect, this approach can be tolerant of faults. Be sure to set "servers:" as described in mh-tailor(8) if you use this option. There are four disadvantages to using the SMTP option: First, only UNIX systems with TCP/IP are supported. Second, you need to have an SMTP server running somewhere on any network your local host can reach. Third, this bypasses any authentication mechanisms in _M_M_D_F or _S_e_n_d_M_a_i_l. Fourth, the file /etc/hosts is used for hostname lookups (although there is an exception file). In response to these disadvantages though: First, there's got to be an SMTP server somewhere around if you're in the Internet or have a local network. Since the server search-list is very general, a wide-range of options are possible. Second, SMTP should be fixed to have authen- tication mechanisms in it, like POP. Third, _M_H won't choke on mail to hosts whose official names it can't verify, it'll just plug along (and besides if you enable the BERK or DUMB configuration options, _M_H ignores the hosts file altogether). _F_i_l_e_s /usr/local/lib/mh-6.8/mtstailor tailor file _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s None _S_e_e _A_l_s_o _M_M_D_F-_I_I: _A _T_e_c_h_n_i_c_a_l _R_e_v_i_e_w, Proceedings, Usenix Summer '84 Confer- ence _S_E_N_D_M_A_I_L -- _A_n _I_n_t_e_r_n_e_t_w_o_r_k _M_a_i_l _R_o_u_t_e_r mh-tailor(8), post(8) _D_e_f_a_u_l_t_s None _C_o_n_t_e_x_t None _B_u_g_s The /usr/local/lib/mh-6.8/mtstailor file ignores the information in the _M_M_D_F-_I_I tailoring file. It should not. [mh.6] MH.6.8 UCI version _3. _B_B_O_A_R_D_S The UCI BBoards facility has two aspects: message reading, and mes- sage delivery. The configuration directives applicable to BBoards are "bboards: on/off/pop/nntp" and "bbdelivery: on/off". _B_B_o_a_r_d _D_e_l_i_v_e_r_y If you enabled BBoards delivery ("bbdelivery: on") during confi- guration, then the initial environment for bboards delivery was set-up during installation. A BBoard called "system" is established, which is the BBoard for general discussion. To add more BBoards, become the "bboards" user, and edit the /usr/bboards/BBoards file. The file support/bboards/Example is a copy of the /usr/bboards/BBoards file that we use at UCI. When you add a BBoard, you don't have to create the files associated with it, the BBoards delivery system will do that automatically. Private BBoards may be created. To add the fictitious private BBoard "hacks", add the appropriate entry to the BBoards file, create the empty file /usr/bboards/hacks.mbox (or whatever), change the mode of this file to 0640, and change the group of the file to be the groupid of the people that you want to be able to read it. Also be sure to add the "bboards" user to this group (in /etc/group), so the archives can be owned correctly. By using the special INVIS flag for a BBoard, special purpose BBoards may be set-up which are invisible to the _M_H user. For example, if a site distributes a BBoard both locally to a number of machines and to a number of distant machines. It might be useful to have two distri- bution lists: one for all machines on the list, and the other for local machines only. This is actually very simple to do. For the main list, put the standard entry of information in the /usr/bboards/BBoards file, with the complete distribution list. For the local machines list, and add a similar entry to the /usr/bboards/BBoards file. All the fields should be the same except three: the BBoard name should reflect a local designation (e.g., "l-hacks"), the distribution list should contain only machines at the local site, and the flags field should contain the INVIS flag. Since the two entries share the same primary and archive files, messages sent to either list are read by local users, while only thoses messages sent to the main list are read by all users. Two automatic facilities for dealing with BBoards exist: automatic archiving and automatic aliasing. The file support/bboards/crontab con- tains some entries that you should add to your /usr/lib/crontab file to run the specified programs at times that are convenient for you. The -12- -13- bboards.daily file is run once a day and generates an alias file for _M_H. By using this file, users of _M_H can use, for example, "unix-wizards" instead of "unix-wizards@brl-vgr" when they want to send a message to the "unix-wizards" discussion group. This is a major win, since you just have to know the name of the group, not the address where it's located. The bboards.weekly file is run once a week and handles old messages (those received more than 12 days ago) in the BBoards area. In short, those BBoards which are marked for automatic archiving will have their old messages placed in the /usr/bboards/archive/ area, or have their old messages removed. Not only does this make BBoards faster to read, but it conveniently partitions the new messages from the old messages so you can easily put the old messages on tape and then remove them. It turns out that this automatic archiving capability is also a major win. At UCI, our policy is to save archived messages on tape (every two months or so). We use a program called _b_b_t_a_r to implement our particu- lar policy. Since some BBoards are private (see above), we save the archives on two tapes: one containing the world-readable archives (this tape is read-only accessible to all users by calling the operator), and the other containing the non-world-readable ones (this tape is kept locked-up somewhere). _B_B_o_a_r_d_s _w_i_t_h _t_h_e _P_O_P If you configured _M_H with "bboards: pop" and "pop: on", then the _M_H user is allowed to read BBoards on a server machine instead of the local host (thus saving disk space). For completely transparent behavior, the administrator may set certain variables in the mtstailor file on the client host. The variable "popbbhost" indicates the host where BBoards are kept (it doesn't have to be the POP service host, but this host must run both a POP server and the BBoards system). The variable "popbbuser" indicates the guest account on this host for BBoards. This username should not be either the POP user or the BBoards user. Usually the anonymous FTP user (ftp) is the best choice. Finally, the variable "popbblist" indicates the name of a file which contains a list of hosts (one to a line, official host names only) which should be allowed to use the POP facility to access BBoards via the guest account. (If the file is not present, then no check is made.) The "popbbuser" variable should be set on both the client and ser- vice host. The "popbbhost" variable need be set only on the client host (the value, of course, is the name of the service host). The "popbblist" variable need be set only on the service host. Finally, on the client host, if a POP service host is not expli- citly given by the user (i.e., "popbbhost" is implicitly used), then _b_b_c will explicitly check the local host prior to contacting the service host. This allows each POP client host to have a few local BBoards (e.g., each host could have one called "system"), and then have the POP -14- service host used for all the rest (a site-wide BBoard might be known as "general"). _B_B_o_a_r_d_s _w_i_t_h _t_h_e _N_N_T_P If you configured _M_H with "bboards: nntp" and "pop: on", then the _M_H user is allowed to read the Network News on a server machine using the standard _b_b_c command. For completely transparent behavior, the administrator may set the "nntphost" variable in the mtstailor file to indicate the host where the Network News is kept. The "nntphost" vari- able should be set only on the client host Finally, on the client host, if an NNTP service host is not explicitly given by the user (i.e., "nntphost" is implicitly used), then _b_b_c will explicitly check the local host prior to contacting the service host. This allows each NNTP client host to have a few local BBoards (e.g., each host could have one called "system"), and then have the NNTP service host used for to read the Net- work News. Reading BBoards via the POP and via the NNTP are mutually exclusive. BBOARDS(5) -15- BBOARDS(5) _N_A_M_E BBoards - BBoards database _S_Y_N_O_P_S_I_S /usr/bboards/BBoards _D_E_S_C_R_I_P_T_I_O_N The BBoards database contains for each BBoard the following infor- mation: _f_i_e_l_d _v_a_l_u_e name the name of the BBoard aliases local aliases for the BBoard (separated by commas) primary file the .mbox file encrypted password leadership password leaders local list maintainers (separated by commas) usernames from the _p_a_s_s_w_d (5) file, or groupnames preceded by `=' from the _g_r_o_u_p (5) file network address the list address request address the list maintainer's address relay the host acting as relay for the local domain distribution sites (separated by commas) flags special flags (see <bboards.h>) This is an ASCII file. Each field within each BBoard's entry is separated from the next by a colon. Each BBoard entry is separated from the next by a new-line. If the password field is null, no password is demanded; if it contains a single asterisk, then no password is valid. This file resides in the home directory of the login "bboards". Because of the encrypted passwords, it can and does have general read permission. _F_i_l_e_s /usr/bboards/BBoards BBoards database _S_e_e _A_l_s_o bbaka(8), bbexp(8), bboards (8), bbtar(8) _B_u_g_s A binary indexed file format should be available for fast access. Appropriate precautions must be taken to lock the file against changes if it is to be edited with a text editor. A _v_i_b_b program is needed. [mh.6] MH.6.8 UCI version BBOARDS(5) -16- BBOARDS(5) _N_A_M_E bbaka - generate an alias list for BBoards _S_Y_N_O_P_S_I_S /usr/bboards/bbaka [system] _D_E_S_C_R_I_P_T_I_O_N The _b_b_a_k_a program reads the BBoards database and produces on its standard output a file suitable for inclusion in either the _M_M_D_F-_I_I aliases file (if the argument `system' is given). If the argument is not given, then _b_b_a_k_a produces on its standard output a file suitable for becoming the /usr/local/lib/mh-6.8/BBoardsAliases file. _F_i_l_e_s /usr/bboards/BBoards BBoards database /usr/local/lib/mh-6.8/BBoardsAliases BBoards aliases file for _M_H _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s None _S_e_e _A_l_s_o bboards(5) _D_e_f_a_u_l_t_s None _C_o_n_t_e_x_t None [mh.6] MH.6.8 UCI version BBEXP(8) -17- BBEXP(8) _N_A_M_E bbexp - expunge the BBoards area _S_Y_N_O_P_S_I_S /usr/bboards/bbexp [-_f_i_r_s_t-_m_e_t_r_i_c] [-_s_e_c_o_n_d-_m_e_t_r_i_c] [bboards ...] _D_E_S_C_R_I_P_T_I_O_N The _b_b_e_x_p program reads the BBoards database and calls _m_s_h to archive the named BBoards (or all BBoards if none are specified). The first-metric (which defaults to 12) gives the age in days of the "BB-Posted:" field for messages which should be expunged. The second-metric (which defaults to 20) gives the age in days of the "Date:" field for messages which should be expunged. Any message which meets either metric will be either archived or removed, depending on what the _B_B_o_a_r_d_s (5) file says. _F_i_l_e_s /usr/bboards/BBoards BBoards database _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s None _S_e_e _A_l_s_o msh(1), bboards(5) _D_e_f_a_u_l_t_s None _C_o_n_t_e_x_t None [mh.6] MH.6.8 UCI version BBOARDS(8) -18- BBOARDS(8) _N_A_M_E bboards - BBoards channel/mailer _S_Y_N_O_P_S_I_S /usr/mmdf/chans/bboards fd1 fd2 [y] /usr/local/lib/mh-6.8/sbboards bboard ... /usr/local/lib/mh-6.8/sbboards file maildrop directory bboards.bboard _D_E_S_C_R_I_P_T_I_O_N For _M_M_D_F, the BBoards channel delivers mail to the BBoards system. For _S_e_n_d_M_a_i_l and stand-alone _M_H, the SBBoards mailer performs this task. For each address given, these programs consult the _b_b_o_a_r_d_s (5) file to ascertain information about the BBoard named by the address. The programs then perform local delivery, if appropriate. After that, with the exception of _s_b_b_o_a_r_d_s running under stand-alone _M_H, the programs perform redistribution, if appropriate. For redistribution, the return address is set to be the request address at the local host, so bad addresses down the line return to the nearest point of authority. If any failures occur during redistribution, a mail message is sent to the local request address. _F_i_l_e_s /usr/local/lib/mh-6.8/mtstailor tailor file /usr/bboards/BBoards BBoards database _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s None _S_e_e _A_l_s_o bboards(5), bbaka(8) _D_e_f_a_u_l_t_s None _C_o_n_t_e_x_t None [mh.6] MH.6.8 UCI version BBTAR(8) -19- BBTAR(8) _N_A_M_E bbtar - generate the names of archive files to be put to tape _S_Y_N_O_P_S_I_S /usr/bboards/bbtar [private] [public] _D_E_S_C_R_I_P_T_I_O_N The _b_b_t_a_r program reads the BBoards database and produces on its standard output the names of BBoards archives which should be put to tape, for direct use in a _t_a_r (1) command. If the argument `private' is given, only private BBoards are con- sidered. If the argument `public' is given, only public BBoards are considered. This lets the BBoards administrator write two tapes, one for general read-access (the public BBoards), and one for restricted access. The default is all BBoards For example: cd archive # change to the archive directory tar cv `bbtar private` # save all private BBoard archives After the archives have been saved to tape, they are usually removed. The archives are then filled again, usually automatically by cron jobs which run _b_b_e_x_p (8). _F_i_l_e_s /usr/bboards/BBoards BBoards database _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s None _S_e_e _A_l_s_o bboards(5), bbexp(8) _D_e_f_a_u_l_t_s None _C_o_n_t_e_x_t None [mh.6] MH.6.8 UCI version _4. _P_O_P For POP (Post Office Protocol) client hosts, you need to edit the /usr/local/lib/mh-6.8/mtstailor file to know about two hosts: the SMTP service host and the POP service host. Normally, these are the same. Change the "localname" field of the mtstailor file of _M_H in the file to be the name of the POP service host. This makes replies to mail gen- erated on the POP client host possible, since _M_H will consider use the hostname of the POP service host as the local hostname for outgoing mail. Also set the value of "pophost" to this value. This tells _i_n_c and _m_s_g_c_h_k to use POP instead of looking for mail locally. Finally, make sure the value of "servers" includes the name of the SMTP service host. The recommended value for "servers" is: servers: SMTP-service-host localhost \01localnet If you want more information on the Post Office Protocol used by _M_H, consult the files support/pop/rfc1081.txt and support/pop/rfc1082.txt which describe the _M_H version of the POP: POP3. For POP service hosts, you need to run a daemon, _p_o_p_d (8). The daemon should start at multi-user boot time, so adding the lines: if [ -f /etc/popd ]; then /etc/popd & echo -n ' pop' >/dev/console fi to the /etc/rc.local file is sufficient. The port assigned to the POP3 protocol is "110". For historical reasons, many sites are using port "109" which is the port assigned to the "POP" (version 1 and 2) protocol. The configuration option "POPSER- VICE" is the name of the port number that _M_H POP will try to use, and defaults to the name "pop". To generate _M_H to use newer assigned port number, in your _M_H config file, add: options POPSERVICE='"pop3"' And on both the POP client and service hosts, you need to define the port that the POP service uses. Add the line: pop3 110/tcp to the /etc/services file (if it's not already there). -20- -21- There are two ways to administer POP: In "naive" mode, each user-id in the _p_a_s_s_w_d (5) file is considered a POP subscriber. No changes are required for the mailsystem on the POP service host. However, this method requires that each POP subscriber have an entry in the password file. The POP server will fetch the user's mail from wherever maildrops are kept on the POP service host. This means that if maildrops are kept in the user's home directory, then each POP subscriber must have a home directory. In "smart" mode (enabled via "DPOP" being given as a configuration option), the list of POP subscribers and the list of login users are completely separate name spaces. A separate database (simple file simi- lar to the _B_B_o_a_r_d_s (5) file) is used to record information about each POP subscriber. Unfortunately, the local mailsystem must be changed to reflect this. This requires two changes (both of which are simple): First, the aliasing mechanism is augmented so that POP subscriber addresses are diverted to a special delivery mechanism. _M_H comes with a program, _p_o_p_a_k_a (8), which generates the additional information to be put in the mailsystem's alias file. Second, a special POP channel (for MMDF-II) or POP mailer (for SendMail) performs the actual delivery (_m_h._6 supplies both). All it really does is just place the mail in the POP spool area. These two different philosophies are not compatible on the same POP service host: one or the other, but not both may be run. Clever mail- system people will note that the POP mechanism is really a special case of the more general BBoards mechanism. In addition, there is one user-visible difference, which the administrator controls the availability of. The difference is whether the POP subscriber must supply a password to the POP server: The first method uses the standard ARPA technique of sending a username and a password. The appropriate programs (_i_n_c, _m_s_g_c_h_k, and possibly _b_b_c ) will prompt the user for this information. The second method (which is enabled via "RPOP" being given as a configuration option) uses the Berkeley UNIX reserved port method for authentication. This requires that the two or three mentioned above programs be _s_e_t_u_i_d to root. (There are no known holes in any of these programs.) To add a POP subscriber, for the first method, one simply follows the usual procedures for adding a new user, which eventually results in adding a line to the _p_a_s_s_w_d (5) file; for the second method, one must edit the POP database file (kept in the home directory of the POP user), and then run the _p_o_p_a_k_a program. The output of this program is placed in the aliases file for the transport system (e.g., /usr/lib/aliases for SendMail). Authentication for POP subscribers differs depending on the two methods. When the user supplies a password for the POP session: under the first method, the contents of the password field for the user's -22- entry in the _p_a_s_s_w_d (5) is consulted; under the second method, the con- tents of the password field for the subscriber's entry in the _p_o_p (5) file is consulted. (To set this field, the _p_o_p_w_r_d (8) program is used.) If you are allowing RPOP, under the first method, the user's ._r_h_o_s_t_s file is consulted; under the second method, the contents of the network address field for the subscriber's entry in the _p_o_p (5) file is consulted. In addition, a third authentication scheme is available. When the APOP configuration option is given, e.g., options APOP='"/etc/pop.auth"' In this case, the server also allows a client to supply authentication credentials to provide for origin authentication and reply protection, but which do not involve sending a password in the clear over the net- work. A POP authorization DB, having as its name the value of APOP con- figuration option, is used to keep track of this information. This file is created and manipulated by the _p_o_p_a_u_t_h (8) program. Because this file contains secret information, it must be protected mode 0600 and owned by the super-user. Hence, your first step after installing the software is to issue # popauth -init which creates and initalizes the POP authorization DB. POP(5) -23- POP(5) _N_A_M_E POP - POP database of subscribers _S_Y_N_O_P_S_I_S /usr/spool/pop/POP _D_E_S_C_R_I_P_T_I_O_N The POP database has exactly the same format as the _B_B_o_a_r_d_s (5) database, although many fields are unused. Currently, only four fields are examined: _f_i_e_l_d _v_a_l_u_e name the POP subscriber primary file the maildrop for the POP subscriber (relative to the POP directory) encrypted password the POP subscriber's password network address the remote user allowed to RPOP This is an ASCII file. Each field within each POP subscriber's entry is separated from the next by a colon. Each POP subscriber is separated from the next by a new-line. If the password field is null, then no password is valid. To add a new POP subscriber, edit the file adding a line such as mrose::mrose:::::::0 Then, use _p_o_p_w_r_d to set the password for the POP subscriber. If you wish to allow POP subscribers to access their maildrops without supplying a password (by using privileged ports), fill-in the net- work address field, as in: mrose::mrose:::mrose@nrtc-isc::::0 which permits "mrose@nrtc-isc" to access the maildrop for the POP subscriber "mrose". Multiple network addresses may be specified by separating them with commas, as in: dave::dave:9X5/m4yWHvhCc::dave@romano.wisc.edu,dave@rsch.wisc.edu:::: To disable a POP subscriber from _r_e_c_e_i_v_i_n_g mail, set the primary file name to the empty string. To prevent a POP subscriber from _p_i_c_k_i_n_g-_u_p mail, set the encrypted password to "*" and set the net- work address to the empty string. This file resides in home directory of the login "pop". Because of the encrypted passwords, it can and does have general read permis- sion. _F_i_l_e_s /usr/spool/pop/POP POP database [mh.6] MH.6.8 UCI version POP(5) -24- POP(5) _S_e_e _A_l_s_o bboards(5), pop(8), popaka(8), popd(8), popwrd(8) _B_u_g_s A binary indexed file format should be available for fast access. Appropriate precautions must be taken to lock the file against changes if it is to be edited with a text editor. A _v_i_p_o_p program is needed. [mh.6] MH.6.8 UCI version POP(8) -25- POP(8) _N_A_M_E pop - POP channel/mailer _S_Y_N_O_P_S_I_S /usr/mmdf/chans/pop fd1 fd2 [y] /usr/local/lib/mh-6.8/spop POP-subscriber ... _D_E_S_C_R_I_P_T_I_O_N For _M_M_D_F-_I_I, the POP channel delivers mail to the POP spool area for later retrieval by POP subscribers. For _S_e_n_d_M_a_i_l, the SPOP mailer performs this task. For each address given, these programs consult the _p_o_p (5) file to obtain information about the POP-subscriber named by the address. The programs then deliver the message to the spool area for the POP-subscriber. _F_i_l_e_s /usr/local/lib/mh-6.8/mtstailor tailor file /usr/spool/pop/POP POP database _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s None _S_e_e _A_l_s_o bboards(5), bbaka(8) _D_e_f_a_u_l_t_s None _C_o_n_t_e_x_t None [mh.6] MH.6.8 UCI version POPAKA(8) -26- POPAKA(8) _N_A_M_E popaka - generate POP entries for SendMail or MMDF-II alias file _S_Y_N_O_P_S_I_S /usr/local/lib/mh-6.8/popaka _D_E_S_C_R_I_P_T_I_O_N The _p_o_p_a_k_a program reads the POP database and produces on its stan- dard output a file suitable for inclusion in the SendMail or _M_M_D_F-_I_I aliases file. The contents of this file divert mail for POP subscribers to the POP channel. _F_i_l_e_s /usr/spool/pop/POP POP database _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s None _S_e_e _A_l_s_o pop(5) _D_e_f_a_u_l_t_s None _C_o_n_t_e_x_t None [mh.6] MH.6.8 UCI version POPAUTH(8) -27- POPAUTH(8) _N_A_M_E popauth - manipulate POP authorization DB _S_Y_N_O_P_S_I_S popauth [-init] [-list] [-user name] [-help] _D_E_S_C_R_I_P_T_I_O_N The _p_o_p_a_u_t_h program allows a POP-subscriber to change the secret value used to generate their authentication credentials. In addi- tion, the super-user or master POP user may use this program to either initialize the database or to print public information from it. _p_o_p_a_u_t_h is useful only when the APOP configuration option is defined. (This configuration option defines the name of the POP authorization DB.) Under normal usage, _p_o_p_a_u_t_h prompts for a new secret, just like the _p_a_s_s_w_d program. It then updates the POP authorization DB accord- ingly. With the `-init' switch, the super-user or master POP user can create a new (or zero the existing) POP authorization DB. With the `-list' switch, the super-user or master POP user can print out public information about the named subscriber (or all subscribers). _F_i_l_e_s /etc/pop.auth.* POP authorization DB _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s None _S_e_e _A_l_s_o popd(8) _D_e_f_a_u_l_t_s None _C_o_n_t_e_x_t None [mh.6] MH.6.8 UCI version POPD(8) -28- POPD(8) _N_A_M_E popd - the POP server _S_Y_N_O_P_S_I_S /usr/etc/popd [-p portno] (under /etc/rc.local) _D_E_S_C_R_I_P_T_I_O_N The _p_o_p_d server implements the Post Office Protocol (version 3), as described in RFC1081 and RFC1082. Basically, the server listens on the TCP port named "pop" for connections and enters the POP upon establishing a connection. The `-p' option overrides the default TCP port. If the POP2 configuration option is defined, then the server also implements version 2 of the protocol. If the APOP con- figuration option is defined, then the server supports a non- standard mechanism for identity-establishment in which authentica- tion credentials are used to provide for origin authentication and reply protection, but which do not involve sending a password in the clear over the network. See _p_o_p_a_u_t_h(8) for more details. _F_i_l_e_s /usr/spool/pop/POP POP database _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s None _S_e_e _A_l_s_o _P_o_s_t _O_f_f_i_c_e _P_r_o_t_o_c_o_l - _v_e_r_s_i_o_n _3 (aka RFC-1081), _P_o_s_t _O_f_f_i_c_e _P_r_o_t_o_c_o_l - _v_e_r_s_i_o_n _3: _E_x_t_e_n_d_e_d _s_e_r_v_i_c_e _o_f_f_e_r_i_n_g_s (RFC-1082), pop(5) _D_e_f_a_u_l_t_s None _C_o_n_t_e_x_t None [mh.6] MH.6.8 UCI version POPD(8) -29- POPD(8) _H_i_s_t_o_r_y For historical reasons, the _M_H POP defaults to using the port named "pop" (109) instead of its newly assigned port named "pop3" (110). See the POPSERVICE configuration option for more details. Previous versions of the server (10/28/84) had the restriction that the POP client may retrieve messages for login users only. This restriction has been lifted, and true POB support is available (sending mail to a mailbox on the POP service host which does not map to a user-id in the password file). [mh.6] MH.6.8 UCI version POPWRD(8) -30- POPWRD(8) _N_A_M_E popwrd - set password for a POP subscriber _S_Y_N_O_P_S_I_S /usr/local/lib/mh-6.8/popwrd POP-subscriber _D_E_S_C_R_I_P_T_I_O_N The _p_o_p_w_r_d program lets the super-user or the master POP user or a "leader" of a POP subscriber change the password field for the POP subscriber in the POP database. This program is very similar to the _p_a_s_s_w_d (1) program. Since only the super-user and the master POP user may change any other fields of the POP database (using an ordinary editor), it is possible for the system administrator to delegate responsibility to others to manage groups of POP subscribers. _F_i_l_e_s /usr/spool/pop/POP POP database _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s None _S_e_e _A_l_s_o pop(5) _D_e_f_a_u_l_t_s None _C_o_n_t_e_x_t None _B_u_g_s Although _p_o_p_w_r_d does locking against other invocations of _p_o_p_w_r_d, editor locking for the POP database in general is not implemented. A _v_i_p_o_p program is needed. [mh.6] MH.6.8 UCI version _5. _M_A_I_L _F_I_L_T_E_R_I_N_G There was a time when users on a UNIX host might have had two mail- drops: one from _M_M_D_F and the other from _U_U_C_P. This was really a bad problem since it prevented using a single user-interface on all of your mail. Furthermore, if you wanted to send a message to addresses on dif- ferent mailsystems, you couldn't send just one message. To solve all these problems, the notion of _m_a_i_l _f_i_l_t_e_r_i_n_g was developed that allowed sophisticated munging and relaying between the two pseudo-domains. _M_H will perform mail filtering, transparently, if given the MF con- figuration option. However, with the advent of _S_e_n_d_M_a_i_l and further maturation of _M_M_D_F, _M_H doesn't really need to do this anymore, since these message transport agents handle it. The mail-filtering stuff is too complicated. It should be simpler, but, protocol translation really _i_s difficult. -31- MF(1) -32- MF(1) _N_A_M_E muinc, musift, uminc, umsift - mail filters _S_Y_N_O_P_S_I_S /usr/local/lib/mh-6.8/muinc /usr/local/lib/mh-6.8/musift [files ...] /usr/local/lib/mh-6.8/uminc /usr/local/lib/mh-6.8/umsift [files ...] _D_E_S_C_R_I_P_T_I_O_N The mail filters are a set of programs that filter mail from one format to another. In particular, _U_U_C_P- and _M_M_D_F-style mail files are handled. _m_u_i_n_c filters mail from the user's _M_M_D_F maildrop into the user's _U_U_C_P maildrop; similarly, _u_m_i_n_c filters mail from the user's _U_U_C_P maildrop into the user's _M_M_D_F maildrop. These two programs respect each system's maildrop locking protocols. _m_u_s_i_f_t filters each file on the command line (or the standard input if no arguments are given), and places the result on the standard output in _U_U_C_P format. The files (or standard input) are expected to be in _M_M_D_F format. _u_m_s_i_f_t does the same thing filtering _U_U_C_P formatted files (or input), and places the _M_M_D_F formatted result on the standard output. No locking protocols are used by these pro- grams. If the files aren't in the expected format, the mail filters will try to recover. In really bad cases, you may lose big. _F_i_l_e_s /usr/spool/mail/ UUCP spool area for maildrops /usr/spool/mail/$USER Location of standard maildrop _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s None _S_e_e _A_l_s_o _P_r_o_p_o_s_e_d _S_t_a_n_d_a_r_d _f_o_r _M_e_s_s_a_g_e _H_e_a_d_e_r _M_u_n_g_i_n_g (aka RFC-886), inc(1) _D_e_f_a_u_l_t_s _C_o_n_t_e_x_t [mh.6] MH.6.8 UCI version MF(1) -33- MF(1) _B_u_g_s Numerous; protocol translation is very difficult. [mh.6] MH.6.8 UCI version RMAIL(8) -34- RMAIL(8) _N_A_M_E rmail - UUCP interface to mail _S_Y_N_O_P_S_I_S rmail address ... _D_E_S_C_R_I_P_T_I_O_N _R_m_a_i_l is intended as a replacement for those systems without _S_e_n_d_- _M_a_i_l or _M_M_D_F. It is normally invoked by _u_u_x on behalf of the remote _U_U_C_P site. For each address, it decides where to send it: either locally, via another _U_U_C_P link, or via the Internet. _R_m_a_i_l implements a crude access control facility by consulting the files Rmail.OkHosts and Rmail.OkDests in the /usr/local/lib/mh-6.8/ directory. Hosts listed in the former file can send messages to anywhere they please. Hosts listed in the latter file can receive messages from anywhere. Note that a host listed in the first file is implicitly listed in the second file. _F_i_l_e_s /usr/local/lib/mh-6.8/mtstailor tailor file /usr/local/lib/mh-6.8/Rmail.OkHosts list of privileged hosts /usr/local/lib/mh-6.8/Rmail.OkDests list of privileged destinations _P_r_o_f_i_l_e _C_o_m_p_o_n_e_n_t_s None _S_e_e _A_l_s_o mf(1) _D_e_f_a_u_l_t_s None _C_o_n_t_e_x_t None [mh.6] MH.6.8 UCI version _6. _M_H _H_A_C_K_I_N_G Finally, here's a little information on modifying the _M_H sources. A word of advice however: _D_O_N'_T If you really want new _M_H capabilities, write a shell script instead. After all, that's what UNIX is all about, isn't it? Here's the organization of the _M_H source tree. conf/ configurator tree config/ compiled configuration constants dist/ distributor doc/ manual entries h/ include files miscellany/ various sundries mts/ MTS-specific areas mh/ standalone delivery mmdf/ MMDF-I, MMDF-II sendmail/ SendMail, SMTP papers/ papers about _M_H sbr/ subroutines support/ support programs and files bboards/ UCI BBoards facility general/ templates pop/ POP facility tma/ Trusted Mail Agent (not present in all distributions) uip/ programs zotnet/ MTS-independent areas bboards/ UCI BBoards facility mf/ Mail Filtering mts/ MTS constants tws/ date routines -35- MH-HACK(8) -36- MH-HACK(8) _N_A_M_E mh-hack - how to hack MH _S_Y_N_O_P_S_I_S big hack attack _D_E_S_C_R_I_P_T_I_O_N This is a description of how one can modify the _M_H system. The _M_H distribution has a lot of complex inter-relations, so before you go modifying any code, you should read this and understand what is going on. ADDING A NEW PROGRAM Suppose you want to create a new _M_H command called "pickle". First, create and edit "pickle.c" in the uip/ directory. Next edit conf/makefiles/uip to include "pickle". This file has directions at the end of it which explain how it should be modified. Next, update any documentation (described below). At this point you can re-configure _M_H. See _m_h-_g_e_n(_8) for instructions on how to do this (basically, you want "mhconfig MH"). ADDING A NEW SUBROUTINE Suppose you want to create a new _M_H routine called "pickle". First, create and edit "pickle.c" in the sbr/ directory. Next edit conf/makefiles/sbr to include "pickle". This file has directions at the end of it which explain how it should be modified. You should modify config/mh.h to define "pickle ();". Similarly, sbr/llib-lsbr should be modified for _l_i_n_t. At this point you can re-configure _M_H. UPDATING DOCUMENTATION Edit whatever files you want in conf/doc/. When documenting a new program, such as "pickle", you should create a manual page with the name "pickle.rf". The file conf/doc/template has a manual page template that you can use. If you are documenting a new program, then you should also update three other files: The file conf/doc/mh.rf should be modified to include the ".NA" section from "pickle.rf". The file conf/doc/mh-chart.rf should be modified to include the ".SY" section from "pickle.rf". Finally, the file conf/doc/MH.rf should be modi- fied to include a ".so pickle.me". Naturally, none of these changes will be reflected in the configuration until you actu- ally run _m_h_c_o_n_f_i_g. _F_i_l_e_s Too numerous to mention. Honest. _S_e_e _A_l_s_o mh-gen(8) [mh.6] MH.6.8 UCI version MH-HACK(8) -37- MH-HACK(8) _B_u_g_s Hacking is an art, but most programmers are butchers, not artists. [mh.6] MH.6.8 UCI version _7. _H_I_D_D_E_N _F_E_A_T_U_R_E_S The capabilities discussed here should not be used on a production basis, as they are either experimental, are useful for debugging _M_H, or are otherwise not recommended. _D_e_b_u_g _F_a_c_i_l_i_t_i_e_s The _m_a_r_k command has a `-debug' switch which essentially prints out all the internal _M_H data structures for the folder you're looking at. The _p_o_s_t command has a `-debug' switch which does everything but actually post the message for you. Instead of posting the draft, it sends it to the standard output. Similarly, _s_e_n_d has a `-debug' switch which gets passed to _p_o_s_t. Some _M_H commands look at envariables to determine debug-mode opera- tion of certain new facilities. The current list of envariables is: MHFDEBUG OVERHEAD facility MHLDEBUG mhl MHPDEBUG pick MHPOPDEBUG POP transactions MHVDEBUG window management transactions MHWDEBUG alternate-mailboxes _F_o_r_w_a_r_d_i_n_g _M_a_i_l The _f_o_r_w and _m_h_l commands have two switches, `-dashmunging' and `-nodashmunging' which enable or disable the prepending of `- ' in for- warded messages. To use `-nodashmunging', you must use an _m_h_l filter file. _S_e_n_d The _s_e_n_d command has two switches, `-unique' and `-nounique', which are useful to certain individuals who, for obscure reasons, do not use draft-folders. "Distribution Carbon Copy" addresses may be specified in the _D_c_c: header. This header is removed before posting the message,and a copy of the message is distributed to each listed address. This could be -38- -39- considered a form of Blind Carbon Copy which is best used for sending to an address which would never reply (such as an auto-archiver). _P_o_s_t_i_n_g _M_a_i_l If you're running a version of _M_H which talks directly to an _S_M_T_P server (or perhaps an advanced _M_M_D_F submit process), there are lots of interesting switches for your amusement which _s_e_n_d and _p_o_s_t understand: -mail Use the _M_A_I_L command (default) -saml Use the _S_A_M_L command -send Use the _S_E_N_D command -soml Use the _S_O_M_L command -snoop Watch the _S_M_T_P transaction -client host Claim to be "host" when posting mail -server host Post mail with "host" The last switch is to be useful when _M_H resides on small worksta- tions (or PC:s) in a network--they can post their outgoing mail with a local relay, and reduce the load on the local system. On POP client hosts, the `-server host' switch is defaulted appropriately using the SMTP search-list mechanism. The _w_h_o_m command understands the last three switches. _8. _C_O_N_F_I_G_U_R_A_T_I_O_N _O_P_T_I_O_N_S This manual was generated with the following configuration options in effect: ________________________________________________________________________ Generation Date August 20, 1993 Primary Directory /usr/local/mh-6.8/ Secondary Directory /usr/local/lib/mh-6.8/ Maildrop Location /usr/spool/mail/$USER POP Support Enabled BBoards using NNTP Enabled Transport System MMDF-II with SMTP ________________________________________________________________________ -40- _C_O_N_T_E_N_T_S Section 1. INTRODUCTION ............................................... 1 Scope of this document ....................................... 1 Summary ...................................................... 1 2. THE MTS INTERFACE .......................................... 3 MH-TAILOR ................................................. 4 MH-MTS .................................................... 10 3. BBOARDS .................................................... 12 BBoard Delivery .............................................. 12 BBoards with the POP ......................................... 13 BBoards with the NNTP ........................................ 14 BBOARDS ................................................... 15 BBAKA ..................................................... 16 BBEXP ..................................................... 17 BBOARDS ................................................... 18 BBTAR ..................................................... 19 4. POP ........................................................ 20 POP ....................................................... 23 POP ....................................................... 25 POPAKA .................................................... 26 POPAUTH ................................................... 27 POPD ...................................................... 28 POPWRD .................................................... 30 5. MAIL FILTERING ............................................. 31 MF ........................................................ 32 RMAIL ..................................................... 34 6. MH HACKING ................................................. 35 MH-HACK ................................................... 36 7. HIDDEN FEATURES ............................................ 38 Debug Facilities ............................................. 38 Forwarding Mail .............................................. 38 Send ......................................................... 38 Posting Mail ................................................. 39 8. CONFIGURATION OPTIONS ...................................... 40 THE RAND MH MESSAGE HANDLING SYSTEM: ADMINISTRATOR'S GUIDE UCI Version Marshall T. Rose _F_i_r_s_t _E_d_i_t_i_o_n: _M_H _C_l_a_s_s_i_c (_N_o_t _t_o _b_e _c_o_n_f_u_s_e_d _w_i_t_h _a _w_e_l_l-_k_n_o_w_n _s_o_f_t _d_r_i_n_k) August 20, 1993 6.8.1 #1[UCI]